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METHOD AND APPARATUS FOR 
REDUCING POWER CONSUMPTION EN A 
COMPUTER SYSTEM USING VIRTUAL 
DEVICE DRIVERS 



FIELD OF THE INVENTION 

The present invention relates to the field of computer 
systems; more particularly, the present invention relates to 10 
reducing power consumption in a computer system using 
device drivers. 

BACKGROUND OF THE INVENTION 

Typically, a computer system contains a processor, a bus, 15 
and other peripheral devices. The processor is responsible 
for executing instructions using data in the computer system. 
The bus is used by the processor and the peripheral devices 
for transferring information between one another. The infor- 
mation on the bus usually includes data, address and control 20 
signals. The peripheral devices comprise storage devices, 
input/output (I/O) devices, etc. Generally, all operations 
being performed in the computer system occur at the same 
frequency. ^ 

Many of today's computer systems include power man- 
agement capabilities. Power management is used to reduce 
the dynamic and static power consumption of a system to 
increase the battery life of a mobile personal computer (PC) 
or to reduce the energy costs associated with a desktop PC. ^ 
Dynamic power is consumed by all components during state 
switching of internal electronic circuits, while static power 
is consumed due to the leakage currents of electronic 
devices. 

The existing power-management techniques in a typical 35 
notebook and desktop PC use specific hardware mechanisms 
to provide maximum power savings. These hardware 
mechanisms use processor specific interrupts (e.g., System 
Management Interrupt (SMI)) and other system activity 
monitoring hardware (e.g., idle timers and hardware trap- ^ 
ping mechanisms) to provide a reasonable amount of power 
conservation. 

Alternatively, some software mechanisms exist, which are 
used today to detect CPU idle conditions in order to put the 
system in an optimum power conservation mode (e.g., 45 
Windows APM driver, DOS POVVER.EXE, etc.). Although 
the available software techniques provide for about seventy 
to eighty percent of power conservation, they do not power 
manage a system beyond CPU idleness. That is, they do not 
detect idleness of I/O devices nor turn off idle I/O devices 50 
during system operation or slow the CPU clock rate, etc. 

In existing power management architecture's, there are 
several dynamic and static power conservation states. One of 
these states is referred to as a fully on or full power on state, 
in which all the components of a typical system are powered, 55 
In this state, all the clocks in the system will be running at 
full speed. This state offers no power savings. Another state 
is referred to as a local stand-by, or partially powered-on, 
state, in which certain temporarily idle local devices in the 
system, such as a floppy device, graphics devices (e.g., 60 
LCD, CRT), hard disk device, etc. are powered down. The 
power to these turned off devices is restored when an 
internal or external system event requires the services of 
these resources. The system maintains idle timers for each of 
these power-manageable devices. The idle timers enter an 65 
expired time-out state when they detect idleness of these 
devices after a pre-defined period of inactivity, and notifies 
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the power management software. This state offers the mini- 
mal amount of power savings in a system. Another state is 
referred to as a global stand-by state, in which most of the 
system devices are powered down with the exception of the 

5 CPU and the system DRAM memory. The clock to the CPU 
is stopped with the DRAM memory operating in an 
extended power conservation mode, sometimes referred to 
as stand-by mode with self refresh. At this point in time, the 
CPU and DRAM are ready to be activated when a system 
event occurs. An example of such a system event is a 
keyboard/mouse click or other system interrupts (e.g., 
IRQ0-IRQ15, NMI, SMI, etc.). The last power management 
state is referred to as hibernation, where the system is put in 
the power-off state. When a system detects an idle condition, 
after a predetermined period of time in the global stand-by 

15 mode, it can initiate a transfer to the hibernation state. In 
such a state, complete system state is saved to the hard disk. 
When the system is turned back on, the hibernation state 
restores the system back to exactly the same state as it was 
before. 

20 Dynamic clock throttling is the state where the dynamic 
power consumed by a CPU is reduced by slowing its clock 
rate. A slow clock to the CPU is emulated by periodic 
assertion and de-assertion of a stpclk (stop clock) signal. 
This slow clock emulation leads to less power consumption 

25 by the overall system. This mode is activated during normal 
operation of a system and it is overlapped with a fully-on 
state to offer additional power savings during the fully-on 
state. 

30 As shown above, the prior art system of power manage- 
ment requires the detection of local and global system 
events. This is typically handled by special hardware or 
power-aware applications and device drivers. The detection 
of system idleness for global stand-by is accomplished by 

35 monitoring their interrupt activity in software or hardware 
using existing methods. If none of the system interrupts are 
activated in a predetermined of time, a global stand-by event 
is generated by the chosen hardware or software mechanism. 
Local activity of individual I/O devices is detected mostly 

^ by dedicated power management hardware. The hardware 
snoops on I/O device resources (e.g., I/O addresses and 
IRQx, etc.). The mapping of the resources is static and 
deterministic and known at system boot-up time. These I/O 
resource mappings do not change over the lifetime of the 

45 current system boot In certain power management imple- 
mentations, the snoop I/O addresses are programmable in 
the I/O hardware, while they are fixed in other systems. The 
deterministic nature of the mappings of these I/O resources 
of the local devices (as per PC-AT/DOS standards) makes it 

^ easy to design standard hardware which is consistent across 
all PC DOS platforms. 

These described methodologies have several inherent 
problems. For instance, each of the I/O devices needs an idle 
timer to monitor the activity. This imposes a restriction on a 

55 number of hardware timers that can be designed into the 
system. Also, most implementations hardcode the I/O trap- 
ping address of the I/O devices to save "gates" This makes 
a system more sensitive to remapping of the I/O resources. 
Furthermore, the existing mechanisms assume that all I/O 

50 devices use standard I/O resource mappings over the life- 
time of the system, i.e., static I/O and IRQx mapping. This, 
in fact, places a severe restriction on the usage of the system 
resources and demands perfect hardware compatibility 
across all platforms. 

65 Power management software in the traditional system is 
completely decoupled from the operating system and appli- 
cation. This makes the system prone to the operating system 
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and power management software performing activities, with 
neither of them being aware of the activities being per- 
formed by the other. This may lead to system crashes where 
a power management interrupt, such as SMI, takes control 
away from the operating system while it is executing in the 5 
middle of a critical section of code. 

The current generation of device drivers in operating 
systems virtualize I/O ports. When the I/O pons are virtu- 
alized, it becomes difficult, and in some cases impossible, 
for the power management software and hardware to detect 10 
any possible remappings. This leads the power management 
hardware to monitor and trap on invalid I/O device 
addresses, thereby generating improper events in the system. 

In a plug-and-play environment, it is assumed that the I/O 
device resource mappings (I/O and IRQx) are no longer 
deterministic or visible to the power management software 
at system boot-up time. Current and future generations of 
operating systems will be based on plug-and-play architec- 
tures, where the I/O resource mapping can and will change ^ 
dynamically during the lifetime of the current system boot. 
When these dynamic remappings of I/O devices do occur, 
there is currently no easy way to communicate to the power 
management hardware and software. 

Also, the existing software power-management tech- ^ 
niques assume that the applications of the associated device 
drivers in the system are APM and PMC aware. This makes 
it difficult to manage a system with applications and drivers 
which are not power aware. 

30 

SUMMARY OF THE INVENTION 

A power management mechanism for use in a computer 
system is described. The computer system comprises a bus, 
a memory for storing data and instructions, and a central 35 
processing unit (CPU). The CPU runs an operating system 
having a power management virtual, device driver 
(PMVxD) responsible for performing idle detection for 
devices. The PMVxD performs idle detection using event 
timers that provide an indicator as to the activity level. The ^ 
PMVxD places idle local devices in a reduced power 
consumption state when no activity has occurred for a 
predetermined period of time. 



BRIEF DESCRIPTION OF THE DRAWINGS 45 

The present invention will be understood more fully from 
the detailed description given below and from the accom- 
panying drawings of various embodiments of the invention, 
which, however, should not be taken to limit the invention ^ 
to the specific embodiments, but are for explanation and 
understanding only. 

FIG. 1 illustrates one embodiment of the power manage- 
ment architecture of the present invention. 

FIG. 2 illustrates one embodiment of the power manage- 55 
ment states of the present invention. 

FIG. 3 illustrates an embodiment of the power manage- 
ment control of the present invention. 

FIG. 4 illustrates one embodiment of the dynamic clock ^ 
throttling mechanism of the present invention. 

FIG. 5 illustrates a timing diagram of the CPU clock 
throttling. 

FIG. 6 a conceptual diagram of the Windows operating 
system in enhanced mode. 65 

FIG. 7 is a block diagram of one embodiment of the 
computer system of the present invention. 
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DETAILED DESCRIPTION OF THE PRESENT 
INVENTION 

A method and apparatus for reducing power consumption 
in a computer system is descnbed. In the following detailed 

5 description of the present invenuon numerous specific 
details are set forth, such as types of I/O devices, idle time 
periods, interrupt types, power management states, etc., in 
order to provide a thorough understanding of the present 
invention. However, it will be appreciated by one skilled in 

10 the art that the present invention may be practiced without 
these specific details. In other instances, well-known struc- 
tures and devices are shown in block diagram form, rather 
than in detail, in order to avoid obscuring the present 
invenuon. 

Some portions of the detailed descriptions which follow 
are presented in terms of algorithms and symbolic repre- 
sentations of operations on data bits within a computer 
memory. These algorithmic descriptions and representations 

^ are the means used by those skilled in the data processing 
arts to most effectively convey the substance of their work 
to others skilled in the art. An algorithm is here, and 
generally, conceived to be a self-consistent sequence of steps 
leading to a desired result. The steps are those requiring 

^ physical manipulations of physical quantities. Usually, 
though not necessarily, these quantities take the form of 
electrical or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipulated. It 
has proven convenient at times, principally for reasons of 

^ common usage, to refer to these signals as bits, values, 
elements, symbols, characters, terms, numbers, or the like. 

It should be borne in mind, however, that all of these and 
similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied 

35 to these quantities. Unless specifically stated otherwise as 
apparent from the following discussions, it is appreciated 
that throughout the present invenuon, discussions utilizing 
terms such as "processing" or "computing" or "calculating" 
or "determining" or "displaying" or the like, refer to the 

40 action and processes of a computer system, or similar 
electronic computing device, that manipulates and trans- 
forms data represented as physical (electronic) quantities 
within the computer system's registers and memories into 
other data similarly represented as physical quantities within 

45 the computer system memories or registers or other such 
information storage, transmission or display devices. 

The present invention also relates to apparatus for per- 
forming the operations herein. This apparatus may be spe- 
cially constructed for the required purposes, or it may 

50 comprise a general purpose computer selectively activated 
or reconfigured by a computer program stored in the com- 
puter. The algorithms and displays presented herein are not 
inherently related to any particular computer or other appa- 
ratus. Various general purpose machines may be used with 

55 programs in accordance with the teachings herein, or it may 
prove convenient to construct more specialized apparatus to 
perform the required method steps. The required structure 
for a variety of these machines will appear from the descrip- 
tion below. In addition, the present invention is not 

60 described with reference to any particular programming 
language. It will be appreciated that a variety of program- 
ming languages may be used to implement the teachings of 
the invention as described herein. 
Overview of the Present Invention 

65 The present invention provides for power management in 
a computer system using virtual device drivers (VxDs). In 
one embodiment, die VxDs of the present invention are 
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provided in the Windows lM operating system manufactured 
by Microsoft® Corporation of Redmond, Wash. The present 
invention provides a power management VxD that controls 
at least a portion of the power management in the computer 
system- Power management in the present invention is 5 
facilitated by the I/O/interrupt/VxD trapping capabilities of 
the VxDs running in the protected mode of the CPU at the 
highest privileged level of the operating system in an 
operating system co-operative manner. The VxD operates at 
the CPU's highest privileged level (ring 0). Therefore, the 10 
VxD of the present invention has access and control over 
system hardware and software components. This enables it 
to operate and respond to power management events much 
faster, with low task switching overheads. In one embodi- 
ment, not only does the VxD interface to other software 15 
(e.g., applications), but it also provides an API interface to 
both real/protected mode programs. 

The present invention allows software to power-manage a 
system with applications and device drivers which are not 
power-aware. In addition, software operates cooperatively 20 
with the existing power-management software infrastructure 
such as, for instance, Advanced Power Management speci- 
fication (APM 1.1), Power Management Coordinator 
(PMC), etc. 

The Windows Environment 25 

The Microsoft® Windows operating environment pro- 
vides a graphical user interface (GUI) which makes Win- 
dows application programs easier to use. Microsoft® Win- 
dows environment runs Windows applications located in the 
extended area of memory above the 1 megabyte boundary 30 
using the protected mode of a processor, such as an Intel 
Architecture Microprocessor, manufactured by Intel Corpo- 
ration of Santa Clara, Calif., the corporate assignee of the 
present invention. 

The Microsoft® Windows 3.1 system can operate in one 35 
of two modes: "standard" mode and "enhanced" mode. The 
standard mode exists so that personal computers equipped 
with older 80286 processors can use the Windows environ- 
ment The enhanced mode of Microsoft® Windows is used 
when Microsoft® Windows is run on a computer system 40 
which uses an 80386 microprocessor or more recently 
available microprocessors such as, for instance, the i486™ 
processor. 

The enhanced mode of Microsoft® Windows operates in 
the protected mode of the Intel Architecture Microproces- 45 
sors (e.g., i386™ processor, i486™ processor, etc.). In this 
manner, the enhanced mode of Microsoft® Windows takes 
advantage of features in the Intel Architecture Microproces- 
sors to offer virtual memory and multitasking operation. The 
processor hardware supports execution of several Windows 50 
applications in protected mode. 

The enhanced mode of Microsoft® Windows supports 
DOS applications using "DOS virtual machines. " In a DOS 
Virtual Machine, the Intel Architecture Microprocessor 
operates in Virtual 8086 mode and uses the virtual memory 55 
feature to provide DOS, device drivers, and Terminate and 
Stay Resident (TSR) programs originally loaded into the 
computer to a DOS virtual machine in extended memory. 
Windows uses the virtual memory system to make the 
application area and the DOS, device drivers, and TSR 60 
programs appear to be a single contiguous block of real 
mode memory. When the microprocessor is operating in 
Virtual 8086 mode within the address area of DOS virtual 
machine, the Virtual 8086 mode microprocessor in unaware 
of any memory outside of the DOS virtual machine. 65 

FIG. 6 provides a conceptual diagram of the Windows 
system in enhanced mode. Referring to FIG. 6, the computer 
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system hardware is represented as a level. The Ring 0 level 
with the Kernel and virtual device drivers (VxDs) is also 
shown, aJong with the system virtual machine and the 
various DOS virtual machines. Windows creates DOS vir- 

5 tual machines by mapping DOS, device drivers, and TSR 
programs in the system VM into the DOS VMs. Therefore, 
all the virtual machines share a region of memory called the 
shared real mode memory. 
The Virtual device drivers (VxDs) at ring 0 are a special 

10 feature of Microsoft® Windows enhanced mode. A virtual 
device driver is actually a routine which manages a system 
resource such that more than one application can use the 
system resource at a time. Virtual device drivers therefore 
support Windows'ability to act as a multitasking operating 

15 system. The virtual device drivers, including the VxD of the 
present invention, have access to a wide range of kernel 
services, including those for hardware management, 
memory management, task scheduling, and communicating 
with other virtual devices. 

20 As illustrated in FIG. 6, all the Windows applications run 
within the system virtual machine which operates in pro- 
tected mode. The Windows Dynamic Link Libraries (DLLs) 
which support Windows applications also run within the 
system virtual machine. 

25 Each DOS application in FIG. 6 runs within its own DOS 
virtual machine. Since the DOS virtual machines usually 
operate in the Virtual 8086 mode of the rnicroprocessor, the 
DOS applications generally only address the 1 Megabyte of 
memory in the DOS virtual machine. 

30 Power Management Architecture 

The power management architecture of the present inven- 
tion is shown in FIG. 1. Referring to FIG. 1, various 
power-aware applications (101, 102) shown make use of an 
APM/PMC device driver 103 at the operating system soft- 

35 ware layer. A power-aware device driver 106 also makes use 
of APM/PMC device driver 103 at the operating system 
software layer. The APM BIOS (Basic Input/Output System) 
hardware 104 controls the APM/PMC device driver 103. 
The APM BIOS 104 also controls hardware 105. 

40 Also shown in FIG. 1, power-unaware applications 
110-112 communicate with PMVxD power management 
software 113. The PMVxD power management software 113 
communicates with a Plug-n-Play (P-n-P) configuration 
manager 114 and the APM/PMC device driver 103 in the 

45 operating system software layer. The PMVxD power man- 
agement software 113 controls hardware. The PMVxD 
power management software 113 controls the VxD con- 
trolled hardware 115 and 116 as well as the power manage- 
ment hardware 117 at the hardware layer. In one embodi- 

50 ment, the VxD controlled hardware 115 and 116 have 
built-in power management capabilities in the form of a 
switch and only needs some type of signal to enable them. 
In one embodiment, the power management hardware 117 
may include hardware necessary for placing certain I/O 

55 devices in a reduced power consumption state. 

The present invention provides for placing a computer 
system in various power management states, or modes of 
operation, using a virtual device driver (VxD) that has I/O, 
device driver and interrupt trapping capabilities. In one 

60 embodiment, the VxD provides support for four power 
management modes: fully-on, local standby, global standby 
and hibernation. The PMVxD of the present invention also 
provides support for clock throttling. The present invention 
may support, only one or more of these modes. Furthermore, 

65 the use of the clock throttling mode depends on whether the 
processor in a computer system includes the required func- 
tionality to provide such a feature (i.e., repeatedly issuing a 



7 



HALT command to the CPU). One embodiment of the 
power management states of the present invention are illus- 
trated in the state diagram in FIG. 2. 

Referring to FIG. 2, state 1 is the fully powered-on state. 
While the system is active, the computer system remains in 5 
the fully powered-on state. Whether the system is active is 
based on device activity of local devices as well as system 
activity (e.g., keyboard stroke, mouse movement, etc.) Once 
one or more local devices are determined to be idle, the 
computer system transitions to state 2 where each idle local io 
device is powered off, such that the computer system enters 
the local standby state with respect to those powered down 
devices. The computer system remains in local standby 
while a local device is idle. As soon as the local device is no 
longer idle, the computer system transitions back to the fully 15 
powered on state. When the computer system determines 
that the entire system is idle (e.g., all the local devices are 
idle), the computer system transitions to state 2 to enter 
global standby. In global standby, the system is placed in 
sleep mode, where it remains until system activity is 20 
detected. At that time, the computer system returns to the 
fully powered on state (0). 

In another embodiment, the system transitions from the 
local standby state directly to the global standby state. That 
is, the computer system does not reenter the fully powered 25 
on state before entering global standby. 
The Power Management Virtual Device Driver (PMVxD) 

The present invention comprises a power management 
virtual device driver (PMVxD) and a set of data structures. 
The data structures are initialized at system boot-up time to 30 
provide command/status information to the PMVxD. The 
PMVxD controls power management and comprises several 
software idle timers, one for each enabled I/O device. The 
idleness of a particular device is detected by monitoring the 
activity of each of the enabled I/O devices. The monitoring 35 
of the enabled I/O devices may be performed by one of the . 
following: I/O port address trapping, chaining into I/O 
device interrupt handlers, trapping on I/O devices driver 
(VxD) accesses, and cliaining into I/O protection fault 
handler, each of which is well-known in the art 40 

Most of these capabilities are provided to the VxD as a set 
of VMM and VxD service calls, which are standard Win- 
dows™ device driver support 

The PMVxD is chained into the system timer interrupt 
which provides the time base for all PMVxD counters. In 45 
one embodiment, the PMVxD uses the occurrence of the 
IRQO to indicate when to monitor the activity of each I/O 
device and also the overall system activity for local and 
global standby modes. In one embodiment the IRQO occurs 
every 55 ms. Thus, in this embodiment a power manage- 50 
ment manager of the PMVxD checks every 55 ms to 
determine whether the local devices have been or arc active 
and whether the system as a whole has been or is active. If 
a device has been inactive for a rjredetennined period of 
time, the power management manager of the PMVxD con- 55 
trols the powering down of the device. The predetermined 
period of time may be of variable length and is set based on 
the desired power savings. Different periods of time may be 
associated with different devices. 

The PMVxD installs handlers for I/O trapping to the I/O 60 
port of each device. Anytime an I/O port access is trapped, 
a corresponding counter is updated (increment/decrement) 
to reflect the activity status. For I/O devices whose I/O 
addresses are virtualized, PMVxD interrupt handler stubs 
(e.g., small pieces of code stored in memory at all times) can 65 
be chained into the original interrupt handlers for each 
specific I/O device. This PMVxD stub handler maintains the 
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idleness of an I/O device, for example, Floppy Disk interrupt 
OEh. The use and operation of a stub handler is well-known 
in the art. 

FIG. 3 illustrates the power management control over- 

5 view. Referring to FIG. 3, the PMVxD 301 is shown 
controlling hardware 302. Software 303 also controls hard- 
ware 302 and places hardware 302 in hibernation mode in 
cooperation with hibernation timer 304. The PMVxD 301 
comprises software timers, including a system events timer 

10 301 A and multiple local events timers, such as a floppy 
events timer 301B, graphics events timer 301C and I/O 
device timer 301D. Each of the local events timers (e.g., 
301B-D) monitor local events via an I/O trap handler, a 
device driver hook handler or a chained-interrupt trap han- 

15 dler as an interface. This interface increments and decre- 
ments the software timers. The system events timer 301 A 
monitors global events via an interface, which may also be 
either an I/O trap handler, a device driver hook handler or a 
chained-interrupt trap handler. Note that in one embodiment 

20 only one of these is employed for each global or local events 
timer. 

At a regular interval, such as at every 55 ms correspond- 
ing to the occurrence of the IRQ0, the power management 
(PM) manager 301E checks the status of each of the events 

25 timers (e.g., 301A-D). When an events timer times-out, the 
PMVxD may turn off the power to the I/O device. That is, 
PM manager 301E causes a handler for that event timer to 
be called. This handler controls the dedicated hardware in 
hardware 302 for removing power to the I/O device. When 

30 activity is detected, PM manager 301E calls the handler 
again to power up the device. Similarly if the system events 
timer times out, PM manager 103E calls the global standby 
handler associated with the system events timer, which when 
run causes the clock to the CPU to be stopped in a manner 

35 well-known in the art, such that the CPU is halted. 

When the CPU has been halted, the hibernation timer 304 
is started. If the hibernation timer times out, an interrupt 
occurs, such as a system management interrupt (SMI) in one 
embodiment Software 303 for the interrupt places the 

40 system in a hibernated state. In response to a system event 
such as, for instance, a keyboard input or cursor control 
device movement, the computer system exits the hibernation 
state and the global standby state. 
PMVxD 301 also includes a slow clock timer 310 for use 

45 with the clock throttling mode. The slow clock timer 310 is 
described below. 

With respect to Plug-and-Play Compliance, the PMVxD 
is part of the O/S and appears as a device driver in the 
system. In a Plug-and-play environment, when the system 

50 resources are remapped to the I/O devices, the PMVxD is 
informed of the changes by the O/S specific configuration 
manager or resource manager. This well-defined interface 
mechanism between the O/S and PMVxD allows it to 
dynamically adapt itself to the changes gracefully. The 

55 present invention provides such capability by having the 
PMVxD register with the configuration manager (CM) and 
instructs the configuration manager to notify it when there 
has been a configuration change. The PMVxD responds to 
the notification in the same manner as when examining the 

60 data structures at system boot-up time. 
Dynamic Clock Throttling 

FIG. 4 illustrates the dynamic clock throttling mechanism 
of the present invention. Referring to FIG. 4, dynamic clock 
throttling is accomplished by the PMVxD operating in the 

65 Windows 3.1 O/S 400 with support from the standard PC 
hardware. Periodic assertion of CPU HALT to CPU 404 by 
the slow clock timer 402 emulates a slower clock timer 
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event. CPU 404 being responsive to the HALT command 
causes a reduction in power consumption. FIG. 5 illustrates 
a timing diagram of the CPU clock throttling. Using speed 
up timers 401, the slow clock timer 402 is de-asserted by a 
variable and periodic interrupt event from the system timer 5 
405 or real-time clock (RTC) 406. 
Data Structures of the PMVxD 

The following tables illustrate one embodiment of the 
data structures of a PM VxD according to the teachings of the 
present invention. These data structures have a one-to-one 10 
correspondence to the programmable hardware power man- 
agement features of the i486SL SuperSet. In one embodi- 
ment, a graphical user interface (GUI) permits changes to be 
made to default values as per the needs of an end user. Tables 
1 and 2 below illustrates the PMVxD initialization data 15 
structures of local devices. 



Struct Local_Device 



{ 

IntFloppyEn/Di; 
Int I larddisk En/Di; 
Int Graphics En/Di; 
IntEtheroet En/Di, 
IntCOMl En/Di; 
IntCOM2 En/Di; 
IntLPT En/Di; 
Int Keyboard En/Di; 
IntCPU En/Di; 
Int Misc En/Di; 
} 

Note: Indicates that Local 
Device Monitoring is 
Enabled or Disabled 



TABLE 1 



Struct Local_DEvems 



i 

IntFloppy IO/Intr/VxD; 
Int i larddisk IO/Intr/VxD; 
Int Graphics IO/Intr/VxD; 
IntEtheraet IO/Intr/VxD, 
IntCOMl IO/Intr/VxD; 
IntCOM2 IO/Intr/VxD; 
IntLPT IO/Intr/VxD; 
Int Keyboard IO/Intr/VxD; 
IntCPU IO/Intr/VxD; 
Int Misc IO/Intr/VxD; 
} 

Note: Indicates the Local 
Device Events thai are 
Monitored 



Struct Local^DStatus 



{ 

IntFloppy On/Off 
Int 1 larddisk On/Off; 
Ont Graphics On/Off, 
IntEtheraet On/Off, 
IntCOMl On/Off, 
IntCOM2 On/Off; 
IntLPT On/Off; 
Int Keyboard On/Off, 
IntCPU On/Off; 
Int Misc On/Off; 
} 

Note: Indicates the Local 
Device Power On/Off 
Status 



Struct Local_Activity 



{ 

IntFloppy Yes/No 
IntHarddisk Yes/No; 
IntGrapbxcs Yes/No; 
IntEthernet Yes/No r 
IntCOMl Yes/No; 
IntCOM2 Yes/No; 
Int LPT Yes/No; 
Int Keyboard Yes /No; 
Int CPU Yes/No ; 
Int Misc Yes/No; 
I 

Note: Indicates that Local 
Device is Active/Inactive 
since last sampling by 
PM manager 



TABLE 2 



Struct Local JDinLNum 



{ 

IntFloppy Num. 
IntHarddisk Num; 
IntGrapbxcs Num; 
IntEtheraet Num, 
IntCOMl Num; 
IntCOM2 Num; 
Int LPT Num; 
Int Keyboard Num; 
IntCPU Num; 
Int Misc Num; 

y 

Note: Indicates the Local 
Device Interrupt Number 
to be monitored as Event 



Struct Local_D.LO.Range 



{ 

IntFloppy IO Range, 
IntHarddisk IO Range; 
IntGiaphics IO Range; 
IntEtheraet IO Range, 
IntCOM IO Range; 
IntCOM2 IO Range; 
Int LPY IO Range; 
Int Keyboard IO Range; 
Int CPU IO Range 
Int Misc IO Range; 
} 

Note: Indicates the Local 
Device IO Range as 
16-bit Start/End Addr. 
Pair 



55 

Table 3 below illustrates the PMVxD initialization data 
structures for global events. 



StnictGlobal_Sys.Events 



{ 

IntAPM_Msg. En/Di; 
IntNMI En/Di; 
IntRINO En/Di; 



TABLE 3 



StructSys_Break.Events 



{ 

IntAPM_Mig. En/Di; 
IntNMI En/Di; 
IntRENG En/Di; 



StructSuspend ..Status 



{ 

IntLocal_Standby On/Off; 
IntGIobal-Standby On/Off; 
IntFully_On On/Off; 
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TABLE 3-continued 



StructGlobal_Sys Events 



StructSys_ Break Events 



StructSuspend_Status 



lntlRQ<0 L5> En/Di, 
Int Misc En/Eh, 
\ 

Note Indicates that System 
Events Monitonng is 
Enabled or Disabled 



lntIRQ<0 15> En/Eh. 
Int Misc En/Di, 
} 

Note Indicates that System 
Events Enabled as 
Break Events 



IntHibemadon On/Off, 
Int Misc On/Off. 

} 

Note Indicates the System 
Power Miser Mode 
Status 



In one embodiment, a user interface for programming the 
power management features is available at an end-user level. 
Such an interface enables the user to specify data for the data 
structures shown above. Note that in one embodiment, this 15 
may be invisible to the user 

In one embodiment, hardware is manipulated directly, for 
example, when the VxD and VMM service calls provided by 
Windows are limited. For instance, in one embodiment, it 
may be necessary to disable the system timer interrupt 20 
during Standby mode. 

In one embodiment, in order to trap I/O address :ranges 
which are virtualized by other VxDs, interrupt chaining or 
use of a device driver hook handler is required. 
Power Managed Hardware and An Exemplary Computer 25 
System 

The various components of a system that may be power 
managed include, but are not limited to, the CPU, generic 
I/O controllers (e.g., graphics, floppy, hard disk, keyboard, 
etc.), serial and parallel interfaces and their associated 30 
devices (e.g., modem, mouse, trackball, trackpad, printers, 
LAN), LAN interfaces, and DRAM memory systems. An 
exemplary computer system is described in FIG. 7 below. 

Referring to FIG. 7, one embodiment of the computer 
system of the present invention is implemented is shown as 35 
700. Computer system 700 comprises a bus or other com- 
munication means 701 for communicating information, and 
a processor 702 coupled with bus 701 for processing infor- 
mation. Processor 702 includes, but is not limited to micro- 
processors such as the Intel™ Architecture Microprocessor, 40 
manufactured by Intel Corporation of Santa Clara, Calif., the 
corporate assignee of the present invention, PowerPC™, 
Alpha™, etc. 

System 700 further comprises a random access memory 
(RAM) or other dynamic storage device 704 (referred to as 45 
main memory), coupled to bus 701 for storing information 
and instructions to be executed by processor 702. Main 
memory 704 also may be used for storing temporary vari- 
ables or other intermediate information during execution of 
instructions by processor 702. Computer system 700 also 50 
comprises a read only memory (ROM) and/or other static 
storage device 706 coupled to bus 101 for storing static 
information and instructions for processor 702, and a data 
storage device 707 such as a magnetic disk or optical disk 
and its corresponding disk drive. Data storage device 707 is 55 
coupled to bus 701 for storing information and instructions. 

Computer system 700 may further be coupled to a display 
device 721, such as a cathode ray tube (CRT) or liquid 
crystal display (LCD) coupled to bus 701 for displaying 
information to a computer user. An alphanumeric input 60 
device 722, including alphanumeric and other keys, may 
also be coupled to bus 701 for communicating information 
and command selections to processor 702. An additional 
user input device is cursor control 723, such as a mouse, a 
trackball, stylus, or cursor direction keys, coupled to bus 701 65 
for communicating direction information and command 
selections to processor 702, and for controlling cursor move- 
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ment on display 721. Another device which may be coupled 
to bus 701 is hard copy device 724 which may be used for 
printing instructions, data, or other information on a medium 

15 such as paper, film, or similar types of media. Furthermore, 
a sound recording and playback device, such as a speaker 
and microphone may optionally be coupled to bus 701 for 
interfacing with computer system 700. 
Note that any or all of the components of system. 700 and 

2Q associated hardware may be used, however, it can be appre- 
ciated that any type of configuration of the system may be 
used for various purposes as the user requires. 

The PMVxD of the present invention requires none or 
very minimal hardware support to achieve comparable or 
better level of power conservation, relative to the prior art 

25 dedicated hardware (SMM) power management techniques 
discussed above. 

The present invention provides power management using 
less hardware. Because less hardware is required, there is 
less power consumption. Thus, the power management 

30 provided by the present invention is a power saver. 

As opposed to the prior art, the present invention allows 
more room for expansion without any hardware penalty. 
Also the I/O devices used in the present invention are not 
required to use standard I/O addresses over the life of the 

35 system. 

The power management mechanism of the present inven- 
tion is closely coupled to the operating system, such that 
each is aware of the other's actions. This allows the present 
invention to avoid system crashes (e.g., when the power 

^ management software interrupts and takes control from the 
operating system when it is executing a critical section of 
code). In other words, the PMVxD of the present invention 
eliminates system crash problems by eliminating blind 
spots. Also, the close coupling allows the PMVxD to be 
aware of dynamic changes in the I/O device state changes. 

45 Furthermore, the present invention does not have to virtu- 
alize I/O ports. There is no difficulty for the PMVxD to 
detect it as such. Thus, the present invention prevents 
monitoring and trapping on invalid I/O device addresses and 
the generation of improper events in the system. 

50 When I/O device addresses do change dynamically during 
the life time of the current system boot, the present invention 
provides an easy environment in which to update and 
reorganize it by simply modifying the data structures and 
their I/O address ranges. 

55 Moreover, the present invention operates with existing 
software power management techniques (e.g., APM 1.1 
spec.) that assumes that applications and the associated 
device drivers in the system be APM-aware to monitor and 
control power management Thus, the PMVxD of the 

60 present invention power manages a system which has tra- 
ditional applications and device drivers, one of which is not 
power-aware. The PMVxD makes the non-power-aware 
Windows applications and device drivers "virtually power 
aware". 

65 The present invention may be extended to operating 
systems like IBM OS/2, Microsoft® Windows NT, Unix, 
etc. 



